1. Field of the Invention
The present invention relates to the field of computers. More specifically, the present invention relates to resource management.
2. Description of the Related Art
Traditionally, resource management is handled by operating system environments. Resource management includes management of CPU time, heap memory, and network bandwidth. Since resource management is typically handled by operating system environments, application and generation of resource management policies are limited by operating system environment constraints and complicated by native/proprietary code or shell scripts necessary to interact with the operating system.
Meeting performance requirements and satisfying various tasks, such as load balancing or preventing denial of service attacks, are difficult if not impossible within the limitations of operating system controlled resource management. Safe languages, such as the Java® language, provide a vehicle for meeting performance requirements and satisfying various tasks that are difficult or impossible within the traditional operating system environment limitations.
A safe language (e.g., Java®, Tcl, TeleScript, etc.) allows untrusted program components to be incorporated in a framework where untrusted program components interact safely and efficiently with other program components. A safe language prohibits a program component from circumventing programming abstractions and access restrictions (e.g., illegal type casts, function calls with arguments of inappropriate type or causing stack overflow). An example design aspect for a safe language is removal of pointers. Many access protection problems stem from a program's ability to forge pointers. A program can use pointers and pointer arithmetic to violate access restrictions by accessing objects as something they are not (e.g., a byte array or an object with the same data layout as the actual object but without its access-restrictions). A safe language can provide separate name-spaces to prevent confusion of variables and functions between programs, and ways to insure provision of a service. Generally, safe languages use one or more of three approaches to ensure that a programs' access privileges are constrained: restrict or disallow access to the underlying system; analyze a program to ensure that it conforms to certain stipulated restrictions; or use a computational model that makes certain actions impossible to implement.
Safe languages are increasingly being used as the primary vehicle for organizing computing resources into applications, network services, etc. As part of this evolutionary trend, safe languages are being used to implement complete computing platforms, assuming responsibilities that have historically belonged to the underlying operating system environment.
However, the conventional use of safe languages to implement complete computing platforms falls short to the extent that safe languages do not provide some of the features of operating system environments. This shortfall and the lack of a standard, programmatic way to manage resources outside of the operating system environment has forced developers to take cognizance of the underlying operating system environment, thus leading to a number of awkward, ad-hoc techniques, limiting the expressiveness of safe languages.